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REMARKS 



Minor amendments have been made to the specification to correct an obvious error. No 
new matter has been introduced with these amendments, which are supported in the specification 
as originally filed (See, for example, Fig. 4B, where the HTTP GET response 480 follows, rather 
than precedes, the TCP request 470; therefore, it is obvious that the phrase deleted herein from 
lines 16 - 1 7 of p. 20 was a cut-and-paste error.) 

Claims 1 - 30 remain in the application. 

I. Claim Objections 

Paragraph 1 of the Office Action dated July 24, 2003 (hereinafter, "the Office Action") 
states that Claims 2 and 5 are objected to because of the term "an HTTP*. This is proper 
grammar. See, for example, (i) the definition for HTTP at http://whatis.techtarget.com, which 
refers to "an HTTP daemon* and so forth; (H) httpt/Zwww.wSc.oi^/protocoK which refers to "an 
HTTP binding"; and (iii) RFC 2616, "Hypertext Transfer Protocol HTTP/1 . 1 which contains 
more than 60 occurrences of " an HTTP" but only 2 occurrences of * a HTTP'\ 

The Examiner is therefore respectfully requested to withdraw this objection. 
Rejection Under 35 U.S.C, ^12 

Paragraph 2 of the Office Action states that Claims 28 - 30 are rejected under 35 U.S.C. 
§112, first paragraph, as foiling to comply with the written description requirement. In particular, 
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the phrase '^ini-directional protocol" is cited. Support for this term in found in Applicant's 
specification on p. 4, lines 3 - 6. As stated therein, TCP is designed as a bi-directional protocol, 
where either party can initiate a message to the other. While this text does not specifically use the 
term ' toi-directionar, it is implied by contrast. In particular, the text states "HTTP, on the other 
hand" (i.e., as contrasted to a bi-directional protocol; emphasis added) uses a mode) therein 
requests are initiated [only] by a client ... the protocol does not provide for server-initiated 
messages". In other words, this sentence is desenbing a uni-dtrectional model: requests can be 
initiated only in one direction, by the client but not by the server. 

Applicant therefore respectfully submits that the term ^mi-directional protocol" is in fact 
supported in his specification, in view of the discussions therein of the HTTP protocol, and the 
Examiner is requested to withdraw this rejection. 

ffl. Rejection Under 35 U.S.C. SIO^ 

Paragraph 3 of the Office Action states that Claims 1 - 4, 6 - 13, 15 - 22, and 24 - 29 arc 
rejected under 35 U.S.C §102(e) as being anticipated by U. S. Patent 6,412,009 to Erickson et al. 
This rejection is respectfully traversed. 

Applicant's independent Claims 1, 10, and 19 specify limitations that include use of a 
"send channel" and a "receive channel". Both of these channels are established between "a first 
component" and "a second component". (See lines 4 - 6 and lines 7 - 8 of Claim 1 , for example). 
Independent Claim 28 also specifics a send channel and a receive channel established between a 
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first component and a second component. (See tines 3 - 5 and lines 6 - 7.) These independent 
claims further specify thai the send channel is used for transmitting client-initiated requests (see 
lines 13-14 of Claim 1 and lines 12-13 of Claim 28), whereas the receive channel is used for 
transmitting server-initiated requests (see lines 15-16 of Claim 1 and lines 14 - 15 of Claim 28). 
Fig. 3 shows these channels as elements 330 (the receive channel) and 340 (the send channel). 
Fig. 4A illustrates use of the send channel 340, and Fig. 4B illustrates use of the receive channel 
330. 

Erickson, on the other hand, uses a single connection for transmitting messages in both 
directions . This is stated throughout Erickson' s disclosure. See, for example, the following 
references: 

Final sentence of the Abstract, referring to "the" bi-directional persistent 

connection, which allows "interleaving" of messages from the client with messages 

"on" [presumably, "of ot <4 froitf'] the server. 

Fig. 3, illustrating a single connection at HTTP tunnel 1 29 

Field of the Invention, which states at col 1, lines 8-9 that "a" persistent HTTP 

tunnel is used 

Lines 57 - 59 of col. 2, which refer again to interleaving messages from the client 
and messages from the server on "the" persistent HTTP tunnel 
Col. 3, lines 27 - 29 also refer to interleaving client-initiated messages and server- 
initiated messages on <6 the" persistent HTTP tunnel 
♦ Col 6 t lines 28 - 30 state that one connection remains active during a series of 
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interleaved messages between the client and server, and lines 33 - 35 state that the 



interleaved messages "alternate between the Web client and the Web server as the 



sender 1 



Notably, lines 53 - 62 of col. 7 specify this use of a single connection as a particular 
advantaee of Erickson's technique. As stated therein, the sending of Telnet messages (which are 
"chunked" within HTTP messages) on the connection "... continues without having a new 
connection established ..." and "Because only one connection is needed during the communication 
flow ... [performance is improved]" (emphasis added). 

Applicant's independent claims all specify use of two channels (Le. 3 the send channel and 
receive channel, as stated above), in contrast to Erickson's technique which uses a single 
connection. Thus, Applicant's independent Claims 1, 10, 19, and 28 are patentably distinct from 
EricksoiL 

Furthermore, Erickson leverages the HTTP 1.1 chunking mechanism to enable keeping the 
single connection alive. See, for example, col 8, lines 21-23, which state that Erickson's use of 
chunking "allows the Web client and host system to exchange a series of messages without having 
to open a new connection". Erickson specifically states that version 1.1 of HTTP is required for 
his invention, in order to provide chunking support (since version 1.0 did not have a chunking 
option). Sec col. 8, lines 16-19. Applicant's invention has no such dependency on HTTP 1J or 
on its chunking ftmctionality. 
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Applicant respectfully submhs that a prima facie case of anticipation has therefore not 
been made out. Accordingly, Applicant submits that Claims 1 - 4, 6 - 13, 15 - 22, and 24 - 29 as 
originally presented are patentable over the cited reference, and the Examiner is respectfiilh/ 
requested to withdraw the §102 rejection thereof. 

IV. Rejection Under 35 U.S.C. SI 03 

Paragraph 4 of the Office Action states that Claims 5, 14, 23, and 30 are rejected under 35 
U.S.C. §1 03(a) as being unpatentable over Erickson in view of the HTTP 1.1 specification 
defined in RFC 2068 (referred to in the Office Action as Fielding). This rejection is respectfully 
traversed. 

As demonstrated above, Erickson does not teach the limitations of Applicant's 
independent claims. Therefore, Erickson cannot be combined with RFC 2068 to teach the 
limitations of Applicant's dependent Claims 5. 14, 23, and 30, 

Furthermore, the Office Action admits that Erickson does not teach use of HTTP GET 
request messages, which are specified as limitations of dependent Claims 5, 14, and 23 (Claim 30 
refers instead to a "read request message") and then cites coL 6, lines 1 4 - 18 of Erickson for the 
motivation to combine Erickson with RFC 2068, However, what is stated in that text has rotting 
to do with HTTP GET messages. Instead, it merely states that HTTP 1 . 1 specifies the chunking 
option. Therefore, the references do not provide a motivation for combining Erickson and RFC 
2068 (and at any rate, a combination thereof would not yield Applicant's claimed invention). 
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Accordingly, Applicant respectfully submits that a prima facie case of obviousness under 
§ 1 03 has not been made out, and the Examiner is therefore requested to withdraw the rejection of 
Claims 5, 14, 23, and 30. 

V. Conclusion 

Applicant respectfully requests reconsideration of the pending rejected claims, withdrawal 
of all presently outstanding objections and rejections, and allowance of all claims at an early date. 



Respectfully submitted, 




Marcia L. Doubet 
Attorney for Applicant 
Reg. Nbr. 40,999 
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